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Abstract. We consider type inference in the Hindley/Milner system 
extended with type annotations and constraints with a particular focus 
on Haskell-style type classes. We observe that standard inference algo- 
rithms are incomplete in the presence of nested type annotations. To 
improve the situation we introduce a novel inference scheme for check- 
ing type annotations. Our inference scheme is also incomplete in general 
but improves over existing implementations as found e.g. in the Glasgow 
Haskell Compiler (GHC). For certain cases (e.g. Haskell 98) our inference 
scheme is complete. Our approach has been fully implemented as part of 
the Chameleon system (experimental version of Haskell). 



1 Introduction 

Type inference for the Hindley/Milner system |Mil78| and extensions |Rem93IPot98IOSW99| 
of it is a heavily studied area. Surprisingly, little attention has been given to the 
impact of type annotations (a.k.a. user-provided type declarations) and user- 
provided constraints on the type inference process. For concreteness, we assume 
that the constraint domain is described in terms of Haskell type classes Jon92 HHPW94 . 
Type classes represent a user-programmable constraint domain which can be 
used to code up almost arbitrary properties. Hence, we believe that the content 
of this paper is of importance for any Hindley/Milner extension which supports 
type annotations and constraints. The surprising observation is that even for 
"simple" type classes type inference in the presence of type annotations becomes 
a hard problem. 

Example 1. The following program is a variation of an example from |J NOOj . 
Note that we make use of nested type annotations. 1 

class Foo a b where f oo : : a->b->Int 
instance Foo Int b 
instance Foo Bool b 



For concreteness, we annotate 1 with Int because in Haskell 1 is in general only a 
number. 



p y = (let f : : c -> Int 
f x = foo y x 
in f , y + (1: :Int)) 

q y = (y + (I : : Int) , let f : : c -> Int 

f x = foo y x 
in f) 

We introduce a two-parameter type class Foo which comes with a method foo 
which has the constrained type Va, b.Foo a b a — > b — > Bool. The two instance 
declarations state that Foo Int b and Foo Bool b hold for any b. Consider 
functions p and q. In each case the subexpression y+(l : : Int) forces y to be of 
type Int. Note that we could easily provide a more complicated subexpression 
without type annotations which forces y to be of type Int. The body of function 
f x = f oo y x generates the constraint Foo Int t x where t x is the type of x. 
Note that this constraint is equivalent to True due to the instance declaration. 
We find that f has the inferred type Vt x .t x — > Int. We need to verify that this 
type subsumes the annotated type f : : c->Int which is interpreted as Vc.c — > 
Int. More formally, we write C g h <Xj < cr a to denote that the inferred type 
<7, subsumes the annotated type a a under some constraint C g . Suppose er, = 
(Va.Ci => ti) and a a — (V6.C a t a ) where there are no name clashes between 
a and b. Then, the subsumption condition is (logically) equivalent to C g \= 
V6.(C a D (3a. C; A U = t a )). In this statement, we assume that |= refers to 
the model-theoretic entailment relation and D refers to Boolean implication. 
Outermost universal quantifiers are left implicit. Note that in our system, we 
only consider type equality rather than the more general form of subtyping. For 
our example, we find that the subsumption condition holds. Hence, expressions 
p and q are well-typed. 

Let's see what some common Haskell implementations such as Hugs HUG 
and GHC |GHCj say. Expression p is accepted by Hugs but rejected by GHC 
whereas GHC accepts q which is rejected by Hugs! Why? 

In a traditional type inference scheme [DM82 , constraints are generated 
while traversing the abstract syntax tree. At certain nodes (e.g. let) the con- 
straint solver is invoked. Additionally, we need to check for correctness of type 
annotations (a.k.a. subsumption check). The above examples show that dif- 
ferent traversals of the abstract syntax tree yields different results. E.g. Hugs 
seems to perform a right-first traversal. We visit f :: c -> Int; f x = foo y x 
first without considering the constraints arising out of the left tuple component. 
Hence, we find that f has the inferred type Mt x .Foo t y t x t x — > Int where 
y has type t y . This type does not subsume the annotated type. Therefore, type 
inference fails. Note that GHC seems to favor a left-first traversal of the abstract 
syntax tree. 

The question is whether there is an inherent problem with nested type an- 
notations, or whether it's simply a specific problem of the inference algorithms 
implemented in Hugs and GHC. 

Example 2. Here is a variation of an example mentioned in Fax03 . We make 
use of the class and instance declarations from the previous example. 
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test y = let f : : c->Int 

f x = foo y x 
in f y 

Note that test may be given types Int — > Int and Bool — > Int. The con- 
straint Foo t y t x arising out of the program text can be either satisfied by 
t y = Int or t y = Bool. However, the "principal" type of test is of the form 
\/t y .(\/t x .Foo t y t x ) t y — > Int. Note that the system we are considering does 
not allow for constraints of the form \/t x .Foo t y t x . Hence, the above example 
has no (expressible) principal type. We note that the situation is different for 
(standard) Hindley/Milner with type annotations. As shown by Odersky and 
Laufer |OL96j , the problem of finding a solution such that o~i (the inferred type) 
is an instance o f o~ a (t he annotated type) can be reduced to unification under 
a mixed prefix Mil92 . Hence, we either find a principal solution <f> such that 
h <p(tJi) < 4>{o~a) or no solutions. Hence, inference for Hindley/Milner with type 
annotations is complete. 

We conclude that type inference for Hindley/Milner with constraints and 
(nested) type annotations is incomplete. The incompleteness arises because the 
subsumption check not only involves a test for correctness of annotations, but 
may also need to find a solution. The above example shows that in our general 
case there might not necessarily be a principal solution. 

In order to resurrect completeness we could impose a syntactic restriction on 
the set of programs. E.g., we could simply rule out type annotations for "nested" 
let-definitions, or require that the types of all lambda-bound variables occurring 
in the scope of a nested annotation must be explicitly provided (although it's 
unclear whether this is a sufficient condition). In any case, we consider these as 
too severe restrictions. 

In fact, the simplest solutions seems to be to enrich the language of con- 
straints. Note that the subsumption condition itself is a solution to the subsump- 
tion problem. Effectively, we add constraints of the form Vb.(C a D (3a.Ci A U — 
t a )) to our language of constraints. Then, \/t y .(yt x .Foo t y t x ) => t y — » Int will 
become a valid type of test in the above example. This may be a potential so- 
lution for some cases, but is definitely undesirable for Haskell where constraints 
are attached to dictionaries. It is by no means obvious how to construct dictio- 
naries HHPW94 for "higher-order" constraints. Furthermore, we believe that 
type inference easily becomes undecidable depending on the underlying primitive 
constraint domain. 

In this paper, we settle for a compromise between full type inference and full 
type checking. We only check for the correctness of type annotations. But before 
checking we infer as much as possible. Our contributions are: 

— We introduce a novel formulation of improved inference for checking annota- 
tions in terms of Constraint Handling Rules (CHRs) Frii95]. While inferring 
the type of some inner expression we can reach the result of inference for 
some outer expression. 

— We can identify a class of programs for which inference is complete. 

— Our approach is fully implemented as part of the Chameleon system |SWj . 
We can type a much larger class of programs compared to Hugs and GHC. 
E.g., ExampleQ]is typable in our system. We refer to |SW| for more examples. 
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(x : Va.D => t) e r 
(Var-VE) P p \= C D [i/a]D 
C,T h x: [i/a]t 



(Abs) 



C, r.x : fa h e : £2 



C,r h Az.e : fa 



fa 



(A PP ) 



C, T h ei : fa ->• fa 
C, r h e 2 : fa 



(Let) 



d,r h ei : fa 
a = fv{C 1 ,t 1 )-fv{r) 
C 2 ,r.(g : Va.Ci =>fa) h e 2 



fa 



(LetA) 



C, T h ei e 2 : fa 
a = fv(Ci,ti) 
C 2 ACi,r.(g : Va.Ci => fa) h ei : fa 
C 2) r.(fl : Va.Ci => fa) h e 2 : fa 



C 2 ,r h let g = ea in 62 : £2 



C 2 ,r h let 



= ei 



in e 2 : fa 



Fig. 1. Hindley/Milner with Type Annotations 



We continue in Section |3 where we formally introduce an extension of the 
Hindley/Milner system with constraints and type annotations. Section [3] is the 
heart of the paper. We first motivate our approach by example before mapping 
the entire type inference problem to CHRs. Type inference then becomes CHR 
solving. In Section 0] we discuss related work and conclude. 

2 Types and Constraints 

We present an extension of the Hindley/Milner system with constraints and type 
annotations. 

■ , , . f-.-.c^t. 

me let , me 

1 / = e 



Expressions 


e :: 


= X 


| Xx.e | e e | let / 


Types 


t :: 


= a 


t->t\Ti 


Type Schemes 


a :: 


= t 


Va.C t 


Constraints 


C :: 


= t -■ 


= t\ Ut\CAC 


CHRs 


R :: 


= U 


i^C\ E7i fa, 



; Un fai C 

We write o to denote a sequence of objects 0\, ...,o„ and o : t to denote 01 : 
fa,...,o„ : i n . W.l.o.g., we assume that lambda-bound and let-bound variables 
have been a-renamed to avoid name clashes. We record these variables in some 
environment r. Note that we consider r as an (ordered) list of elements, though 
we commonly use set notation. We denote by {x\ : o\, . . . ,x n : cr n }.x : a the 
environment {xi : a\, . . . , x n : <r n , x : cr}. 

Our type language consists of variables a, type constructors T and type 
application, e.g. T a. We use common notation for writing function and list 
types. We also make use of pairs, integers, booleans etc. in examples. 

We find two kinds of constraints. Equations fa = fa among types fa and ti 
and user-defined constraints U t. We assume that U refers to type classes such 
as Foo. For our purposes, we restrict ourselves to single-headed simplification 
CHRs U i <^=4> C and multi-headed propagation CHRs [fa fa,...,J7„ t n C. 
We note that CHRs describe logic formula. E.g. U i C can be interpreted 
as Va.C/ t <-> (36. C) where a = fv(t) and 6 = fv(C) — a, and [fa fa, U„ t n =4> C 
can be interpreted as Va.([fa fa A ... A U n t n ) D (36. C) where a = fv(Ji, ■■■,t n ) 
and 6 = fv(C) — a. Via CHRs we can model most known type class extensions. 
We refer the interested reader to SS04 for a detailed account of translating 
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classes and instances to CHRs. We claim that using CHRs we can cover a suf- 
ficiently large range of Hindley/Milner type systems with constraints such as 
functional dependencies, records etc. Note that CHRs additionally offer multi- 
headed simplification CHRs which in our experience so far do not seem to be 
necessary in the type classes context. Due to space limitations, we only give one 
simple example showing how to express Haskell 98 type class relations in terms 
of CHRs. 

We assume that the meaning of user-defined constraints (introduced by class 
and instance declarations) has already been encoded in terms of some set P p of 
CHRs. User-defined functions are recorded in some initial environment /init- 

Example 3. Consider 

class Eq a where (==) : : a->a->Bool 
instance Eq a => Eq [a] 

class Eq q => Ord a where (<) : : a->a->Bool 
class Foo a b where f oo : : a->b->Int 
instance Foo Int b 
instance Foo Bool b 



Note that the declaration class Eq a => Drd a introduces a new type class 
Ord and imposes the additional condition that Ord a implies Eq a (which is 
sensible assuming that an ordering relation assumes the existence of an equality 
relation). We can model such a condition via a propagation rule. Hence, P p 
consists of 

(Super) Ord a =>■ Eq a (Fl) Foo Int b True 
(Eql) Eq a <^ Eq [a] (F2) Foo Bool b -t=> True 

and Finn = {(==) : ^a.Eq a =>• a — ► a — * Bool, (<) : Va.Ord a =>■ a — > a — > 
Bool, foo : Va, b.Foo a b =>• a — > b — ► Int}. 

We introduce judgments of the form C, T h e : t where C is a constraint, 
r refers to the set of lambda-bound variables, predefined and user-defined func- 
tions, e is an expression and t is a type. We leave the type class theory P p im- 
plicit. We say a judgment is valid iff there is a derivation w.r.t. the rules found 
in Figure n Commonly, we require that constraints appearing in judgments are 
satisfiable. We say that a valid judgment is satisfiable iff all constraints appear- 
ing in the derivation are satisfiable. A constraint is satisfiable w.r.t. a type class 
theory iff we find some model satisfying the theory and constraint. We say a 
theory P p is satisfiable iff we find some model for P p . 

In rule (Var-VE), we assume that x either refers to a lambda- or let-bound 
variable. Note that only let-bound variables and primitives can be polymorphic. 
For convenience, we combine variable introduction with quantifier elimination. 
We can build an instance of a type scheme if the instantiated constraint is 
entailed by the given constraint w.r.t. type class theory P p . 

In rule (Let) we couple the quantifier introduction rule with the introduction 
of user-defined functions. In our formulation, C2 does not necessarily guarantee 
that C\ is satisfiable. However, our rule (Let) is sound for a lazy semantics which 
applies to Haskell. 
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Rule (LetA) introduces a type annotation. Note that we assume that type 
annotations are dosed, i.e. all variables appearing in C\ t\ are assu med to 
be universally quantified. This is the assumption made for Haskell 98 [Has]. 
Note that the environment for typing the function body includes the binding 
g : Va.Ci =>■ t\. Hence, we allow for polymorphic recursive functions. 

The other rules are standard. Note that we left out the rule for monomorphic 
recursive functions for simplicity. 

3 Type Inference via CHRs 

We introduce our improved inference scheme first by example. Then, we show 
how to map the typing problem to a set of CHRs. We give a description of the 
semantics of CHRs adapted to our setting. Finally, we show how to perform type 
inference in terms of CHR solving. 

3.1 Motivating Examples 

The following examples give an overview of the process by which we abstract 
the typing problem in terms of constraints and CHRs. 

Example J±. Consider the following program. 

g y = let f x = x in (f True, f y) 

We introduce new predicates, (special-purpose) user constraints, g(t) and 
f(t) to constrain t to the types of functions g and f respectively. It is necessary 
for us to provide a meaning for these constraints, which we will do in terms of 
CHR rules. The body of each rule will contain all constraints arising from the 
definition of the corresponding function, which represent that function's type. 

For the program above we may generate rules similar to the following. 

g(t) <^=^ t = t v -> (t 1 ,t 2 ), f(t fl ),t fl = Bool -> ti,f(tf 2 ),t f2 = t y -> f 2 
f(t) *=>t = t*->t x 

The arrow separating the rule head from the rule body can be read as logical 
equivalence. Variable's mentioned only in a rule's body are implicitly existentially 
quantified. 

In the g rule we see that g's type is of the form t y — > (ti, t%), where t\ and t 2 
are the results of applying function f to a Bool and a t y . We represent f 's type, 
at both call sites in the program, by the / user constraint. 

The / rule is much more straightforward. It simply states that t is /'s type 
if t is the function type t x — ► t x , for some t x , which is clear from the definition 
off. 

We can infer g's type by performing a CHR derivation, solving the constraint 
g(t) by applying CHRs (removing the constraint matching the lhs with the rhs). 
Note that we avoid renaming variables where unnecessary. 



g{t) t = ty -» (t 1 ,t 2 ),f(tf 1 ),t fl = BOOl -> h,f(tf2),tf 2 =ty ~» f 2 

*~^f t = ty ^> {tl,t 2 ),tfl = t X — > t X , tfl = BOOl — > t\, f(tf 2 ),tf 2 = ty —> f 2 

*~*f t = ty ^> {tl,t 2 ),tfl = t x — * t x , tfl = BOOl — > tl,tf 2 =t x —* t' x , tf 2 = ty 

If we solve the resulting constraints for t, we see that g's type is \/t y .t y — > 

{Bool, ty). 
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Example 5. The program below is a slightly modified version of the program 
presented in Example 0] 



g y = let f x = (y,x) in (f True, f y) 

The key difference is that f now contains a free variable y. Since y is monomor- 
phic within the scope of g we must ensure that all uses of y, in all definitions, 
are consistent, i.e. each CHR rule which makes mention of t y , y's type, must 
be referring to the same variable. This is important since the scope of variables 
used in a CHR rule is limited to that rule alone. 

In order to enforce this, we perform a transformation akin to lambda-lifting, 
but at the type level. Instead of user constraints of form f(t) we now use binary 
constraints fit, I) where the I parameter represents f 's environment. 

We would generate rules like the following from this program. 

g(t,l) t = t y —> (ti,t 2 ), f(tfi),tfi = Bool -> ti, f(tfa, (tx)),tf 2 = t y — ► f 2 ,l = Is 
f(t,l)^t = t x -» (*„,*„),*= (<*y|*«» 

We write (t\, t n ) to indicate a type-level list containing n types. A list with 
an n-element prefix but an unbounded tail is denoted by (ti, t n \t). When uni- 
fying such a type against another list, t will be bound to some sublist containing 
all elements after the nth. 

As mentioned above, we now use binary predicates to represent the type of a 
function. The first argument, which we commonly refer to as the t component, 
will still be bound to the function's type. The second component, which we call I, 
represents a list of unbound variables in scope of that function. We have ensured 
that whenever the / constraint is invoked from the g rule that t y , the type of y, 
is made available to it. So, in essence, the t v that we use in the / rule will have 
the same type as the t y in g, rather than simply being a fresh variable known 
only in g. 

Example 6. We now return to the program first introduced in Example ^ an d 
generate the CHR rules corresponding to the function p, which is repeated below. 
For simplicity we will assume that (+) is defined only on Ints, i.e. (+) : Int — > 
Int — > Int. 

p y = (let f : : c -> Int 
f x = foo y x 
in f , y + (1 : : Int)) 

We generate the following CHRs from this fragment of the program. We also 
include the rule which represents f oo's type, and the rule which corresponds to 
the instance Foo Int b. 



p(t,l) 




Int — > t r ,l = (Is, (t y ,t x )) 



fait, I) 
f{t,l) 



t-n fait, t), 
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Here we have extended the scheme which we used to generate the constraints 
in the previous example. We stick to binary predicates, but have expanded the 
I component to include two lists. The first list, which we refer to as the local I 
component contains, as before, a type-level list of all unbound lambda variables 
in scope of the function. The second list, which we will often denote LT simply 
contains all of the lambda-bound variables from the top-level definition down, 
in a fixed order. 

We introduce a symbol f a and generate a new rule to represent f 's annotated 
type. Note also that we add a call to the / rule to unify f 's inferred type with 
the declared type. 

As demonstrated earlier, in order to check f it is necessary to consider all 
of the type information available in f 's context. In particular, for this program, 
it is critical that we know y has type Int, in order to reduce the Foo Int b 
constraint which arises from the use of foo, but is absent from the annotation. 

The way we introduce f 's context into f is by adding a call from the f a rule 
to the immediate parent definition, which in this case is represented by p. In this 
instance we are not interested in p's type, only the effect it has on lambda-bound 
variables, and any type class constraints which may arise. Note that if p were 
itself embedded within a function definition, then it too would have such a call 
(to its own parent), and so f would indirectly inherit p's context. 

We perform the following simplified derivation to demonstrate that the CHR 
formulation above captures the necessary context information within f . 

f(t,l) >->/ f00(tf oo ,ls'),tf oo = ty ->t x ->t r ,f a (t,l), 
l=((t y ),(ty,t x )),... 

M /oo tfoo = a — > b — » Int, Foo a b, tf oa = t y — > t x — > t r , f a (t, I), 

l=((ty),(ty,t x )),... 

we can simplify this to: 

FOO ty t X ,f a (t, I), I = {(ty), (ty,t X )), ... 
>->/„ FOO ty t X ,p(t',l),l = ((ty), (ty,t X )), ... 

^ p Foo t y t x , t p i us = Int — > Int — > Int, t p i us = t y — > Int — > t r , 

l=(lS, (ty,t X )),l={(ty),(ty,t X )),... 

> > Foo tpius = Int > Int ► Int, tpi us = ty y Int ► t r , 
I (IS, (ty, t x )), I — ((ty), (ty, t x )), ... 

Through the call to p from f a we introduce sufficient context information to 
determine that t y is an Int, and to consequently reduce away the Foo constraint 
using the instance rule. Note that the LT component is necessary here because 
p is not aware of its own lambda-bound variables. Without the LT component, 
p would not be able to "export" the required information about t y to /. 

3.2 Constraint and CHR Generation 

In detail, we show how to map expressions to constraints and CHRs. Lambda- 
abstractions such as Xx.e are preprocessed and turned into Ax :: t x .e where t x 
is a fresh type variable. We assume that LT contains all such type variables t x 
attached to lambda-abstractions. 

For each function definition f =e we generate a CHR of the form f(t, I) C 
where I refers to a pair (7;, l g ). The constraint C is generated out of the program 
text of e. We maintain that k denotes the set of types of lambda-bound variables 
in the environment and l g refers to LT the types of all lambda-bound variables. 
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Constraint Generation: 

t,l,l g fresh (/ € E or 
(g : ti) 6 r fa fresh f a eEf non-recursive) 

( J p,p,* h c (t 2 = tilt 2 ) 1 j <? = {/(*,*),* = ((fa), W 

h c (Cli) 

faSEf recursive t, I l g fresh C = {f a {t, I), I = ({tl, Z g ))} 
(VarA_t) {x:t x \,E,f h c (6'K) 

r.x : ii, P, e h c (C 1 fa) P, E, ei h c (Ci I ti) 

(Abs) C" = {C,t 3 = -> fa} fa fresh (App) r, P, e 2 h c (C 2 1 fa) fa fresh 



r,E,Xx::h.e h c (C I fa) P,P,ei e 2 h c (Ci, C 2 , ti = fa fa I fa) 

r,EU {9 },e^c(C\t) r,EU {9a },e^ c (C\t) 



(Let) /'. /-..let >/ (L " tA - ) .■.— »::<', *t 

CHR Generation 



r,E,\et g = ei in e 2 h c (C 1 1) V j P, P, let ff 1 1 in e 2 h c (C It) 

g = ei 



h,r,E,ei h fl Pi 
(Var) ft,P,P,i; h fl (App) h,r,E,e 2 h R P 2 (Abs) 



ft, r, P, ei e 2 h fl Pi U P 2 



h,T,E,Xx :: t.e h fl P 



P = {cci : ti,... ,i„ : t n ] t,t' 2 ,l,lr,lg fresh 
, . g,T,E,ei h fi Pi /i,P,PU{<?},e 2 h fl P 2 P,P,ei h c (C*; It'i) 
1 6 j P = PiUP 2 U{g(t,l)^C' 1 ,t' 1 = t,l = {{t 1 ,...,t n \lr),LT),h(t' 2 ,l) e } 

h, r, E, let g = ei in e 2 h_R P 

P = {a;i : ti, . . . , x n : tn} t, t 2 , Z, Zr fresh 
<?, P, P U {g a }, ei h fl Pi ft, P, P U {g a }, e 2 h fl P 2 P, P U {<?„}, ei h c (Ci I ti) 

P = Pi U P 2 U 

(LetA) / g a (t, l)^t = t'/, Ci', I = «ti, t n \lr),LT),h{t' 2 ,l) e 

g (t, I) ^l = ((t 1 ,....t n \lr), LT), g a (t, I), C' u t = tj 

ft,P,P,let ff " 0l ^ 1 in e 2 h R P 

g = ei 



Fig. 2. Constraint and CHR Generation 



We make use of list notation (on the level of types) to refer to the types 
of A-bound variables. In order to avoid confusion with lists of values, we write 
(Zi, . . . , l n ) to denote the list of types Zi, . . . , l n . We write (l\r) to denote the list 
of types with head I and tail r. 

For constraint generation, we employ judgments P, E, e he (CI t) where 
environment P, set of predicate symbols E and expression e are input values and 
constraint C and type t are output parameters. Note that P consists of lambda- 
bound variables only whereas E holds the set of predicate symbols referring to 
primitive and let-defined functions. Initially, we assume that E init holds all the 
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symbols defined in Pi n u which is the CHR representation of all functions in Pi n it . 
The rules can be found in Figure |21 

Consider rule (Var-f). If the function does not carry an annotation or the 
function is not recursive 2 we make use of the definition CHR. However, strictly 
making use of the definition CHR might introduce cycles among CHRs, e.g. con- 
sider polymorphic recursive functions. In such cases we make use of the annota- 
tion CHR, see rule (VarA-f). In both rules we set I to the sequence of types of 
all lambda-variables in scope. Note that we might pass in more types of lambda- 
bound variables than expected by that function. This is safe because we leave 
the first component of I "open" at definition sites. That is, we expect at least 
the types of lambda-bound variables in scope at the definition site and possibly 
some more. The second component which refers to the sequence of all types of 
lambda-bound variables appearing in the entire program is left unconstrained. 
This component will be only constrained at definition sites (see CHR generation 
rules (Let) and (Let A)). Note that in rule (Abs) the order of lambda-bound 
variables added to type environment matters. Hence, we silently treat r as a list 
rather than a set. In rules (Let) and (Let A) the constraints arising out of ei might 
not appear in C unless we use function g in e-i- Note that we do not generate a 
constraint for the subsumption condition which will be checked separately. 

For rule generation, we employ judgments of the form h, -T, E, e h# P where 
CHR h, environment r, set of predicate symbols E and expression e are input 
values and the set P of CHRs is the output value. As an invariant we maintain 
that h refers to the surrounding definition of expression e. Initially, we assume 
that h refers to some trivial CHR h(t, I) •<=>• True and E refers to the set of 
primitive functions. We refer to Figure |21 for details. There are two interesting 
rules. 

Rule (Let) deals with unannotated functions. Note that we do not add g to E 
when generating constraints and rules from e\. Hence, we assume for simplicity 
that unannotated functions are not allowed to be recursive. Of course, our sys- 
tem SW handles unannotated, recursive functions. Their treatment is described 
in a forthcoming report The novel idea of our inference scheme is that we reach 
surrounding constraints within the definition of g via the constraint h(t2,l)s- 
The e marker (left out in Example for simplicity) serves two purposes: (1) We 
potentially create cycles among CHRs because we might reintroduce renamed 
copies of surrounding constraints. Markers will allow us to detect such cycles to 
avoid non-termination of CHRs. (2) Variables occurring in marked constraints 
are potentially part of the environment. Hence, we should not quantify over those 
variables. Examples will follow shortly to highlight these points. 

Rule (Let A) is similar to rule (Let). Here, the annotation CHR includes the 
surrounding definition h. The actual inference result is reported in the definition 
CHR. 

3.3 CHR Solving 

We introduce the marked CHR semantics. We assume that each constraint is 
attached with either a q marker or a e (pronounced empty) marker. The empty 
marker is commonly left implicit. We refer to constraints carrying a q marker 
as marked constraints. A constraint carrying the empty marker is unmarked. In 

2 We can easily check whether a function is recursive or not by a simple dependency 
analysis. 
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case of CHR rule application on a marked constraint, we mark all constraints in 
the body before adding them to the constraint store. 

Definition 1 (Marked CHR Application). Let d = (U t) a (or d = f(t) a ) 
be a primitive constraint where a G {e, e }. We define mark(d) = a. We write 
d e to denote (U t) e (or f(t) e ). 

Let (R) c\,...,c n =>■ d\,...,d m G P and C be a constraint. Let <fi be the 
m.g.u. of all equations in C. Let d x ,...,d n G C such that there exists a substitution 
9 on variables in rule (R) such that 6{ci) = ^(c-) for i = l...n. Then, C 
C, d[, d' m where 

d , = f d t ifmark(c' ) ^ e for j = l...n 
1 \ (di)e otherwise 

Let (R) c <^==> d\, ...,rf m G P and C be a constraint. Let <j> be the m.g.u. of 
all equations in C . Let c' G C such that there exists a substitution on variables 
in rule (R) such that 8(c) = <f)(c'), that is user-defined constraint c' matches the 
left-hand side of rule (R). Then, C C — c', d[, ■■■,d' m where d' { are as above. 

A derivation step from global set of constraints C to C using an instance of 
rule r is denoted C ^ r C . A derivation, denoted C C is a sequence of 
derivation steps using either rules in P such that no further derivation step is 
applicable to C". The operational semantics of CHRs exhaustively apply rules to 
the global set of constraints, being careful not to apply propagation rules twice 
on the same constraints (to avoid infinite propagation). We say a set of CHRs 
is terminating if for each C there exists C such that C C . 

Example 7. Consider 

class Erk a where erk : : a 
class Foo a where f oo : : a 

f = (erk, let g : : Foo a => a; g = foo in g) 

Here is a sketch of the translation to CHRs. 

9a(t) f(t%,Foo t f(t) t = (a,b),Erk a,g(b) 
g(t)^g a (t),Foot 

Consider the derivation 

gjti) ^-> g g a (ti), Foo ti ^ ga f(t') e ,Foo h 
>->/ t' = (a,b), (Erk a) e , g(b) e , Foo h 
^ g t' = (a,b), (Erk a) e , g a (b) e , (Foo b) e ,Foo t x 

In step >— »/ we propagate to all new constraints. Note that we encounter 
a cycle among CHRs (see underlined constraints). Indeed, CHRs may be "non- 
terminating" because we introduce repeated duplicates of surrounding constraints 
To avoid non-termination we introduce an additional CHR Cycle itemoval step 



^ g t' = (a, b), (Erk a) e , g a (b) e , (Foo b) e , Foo ti 
^ccr t' = (a, b), (Erk o) e , (Foo b) e ,Foo h 

which is defined as follows. 
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Definition 2 (CHR Cycle Removal). Let f(t,l) G C and f(t',l') e G C 
and a derivation ... >— > C >— » ... >— > C . Then, ...>—» C >—►...>—► C ^ccr 
C'-f(t'J%. 

We assume that ^->ccr is applied aggressively. 

We argue that this derivation step is sound because any further rule appli- 
cation on <7a(&)e "vvill only add renamed copies of constraints already present in 
the store. 

Lemma 1 (CCR Soundness). Let P be a set_of CHRs and C and C two 

constraints such that C ^->p C . Then P \= C <-> 3f v (c)C . 

We can also argue that we break any potential cycle among predicate sym- 
bols referring to function symbols. Note that we do not consider breaking cycles 
among two unmarked constraints. Such cases will only occur in case of unanno- 
tated, recursive functions which are left out for simplicity. A detailed description 
of such cases will appear in a forthcoming report. Also note that we never re- 
move cycles in case of user-defined constraints. In such a case, the type class 
theory might be non-terminating. Hence, we state the the CCR derivation steps 
preserves termination assuming the type class theory is terminating. 

Lemma 2 (CCR Termination). Let P p be a terminating type class theory, 
h(t, I) <f=^- True a CHR, Ei n i t a set of primitive predicate symbols, Pi n u a set of 
CHRs and (T, e) a typing problem such that h, T, Ei n u, e \-r P e and (Pinit , Pinit) 
models Ei n %t for some Tmit ■ Then, P p U P e U Pinit is terminating. 

3.4 Type Inference via CHR Solving 

Consider type inference for an expression e w.r.t. an environment T of lambda- 
bound variables and an environment Pinit of primitive functions and type class 
theory P p . We assume (Pint, Eint) model Pinit such that for each / : Va.C =^ t' we 
find f(t, I) <^=> C,t — t' G Pinit and / G E init . Then, we generate T, e \~c (CI t) 
and h, T, E init ,e \- R P e . We generally assume that P denotes P p U P e U Pinit- 

For typability we need to check that (1) constraint C is satisfiable, and (2) 
all type annotations in e are correct. We are now in the position to describe 
CHR-based satisfiability and subsumption check procedures. 

Definition 3 (Satisfiability Check). 

Let P be a set of CHRs and C a constraint such that C C for some 

constraint C . We say that C is satisfiable iff the unifier of all equations in C 
exists. 

Soundness of the above definition follows from results stated in [5^02 in combi- 
nation with Lemma[l] Of course, decidability of the satisfiability check depends 
on whether CHRs are terminating. 

To check for correctness of type annotations we first need to calculate the 
set of all subsumption problems. Let E su i,^ be the set of all predicate symbols 
g a where each g a refers to some subexpression (let g :: C\ ^ t\\g — e\ in C2) 
in e. Let F su b( e ) be a formula such that yt,l.(g a (t,l) «-» g(t,l)) G F su ^ e ) for all 
g a G -E su 6( e ) . It remains to verify that the type annotation is correct under the 
abstraction of type inference in terms of P. Formally, we need to verify that 
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P \= F sub r e \ where P refers to first-order logic interpretation of the set of CHRs 
P. In |SS02| . we introduced a CNF (Canonical Normal Form) procedure to test 
for equivalence among constraints Vi, l.(g a (t, I) «-> g(t, I)) w.r.t. some set of CHR 
by executing g a (t,l) and g{t,l) and verify that the resulting final stores are 
equivalent modulo variables in the initial store (here {/, I}). Thus, we can phrase 
the subsumption check as follows. We write 3 t j.C to denote 3fv(C) — {t, 1}.C. 

Definition 4 (Subsumption Check). Let g a G E sub ^ and P be a set of 

CHRs. We say that g's annotation is correct iff (1) we execute g a (t,l) >-^>p G\ 
and git, I) ^->* P Ci, (2) we have that |= (3 tj ;.Ci) <-» (EI^.C^). 

Soundness of the above definition follows from results stated in |SS02j in com- 
bination with Lemma n 

Example 8. Recall Examplc|7|and the derivation g(t\) ^* t' = (a,b), (Erk o)q, Footi. 
A similar calculation shows that g a (ti) ^* s' = (c,d),(Erk c) e ,Foo t\. Note 
that the resulting constraints are logically equivalent modulo variable renamings. 
Hence, g's annotation is correct. 

Note that in our formulation of type inference, the type of an expression is 
described by a set of constraints w.r.t. a set of CHRs. The following procedure de- 
scribes how to build the associated type scheme. Markers attached to constraints 
provide important information which variables arise from the surrounding scope. 
Of course, we need to be careful not to quantify over those variables. 

Definition 5 (Building of Type Schemes). Let P be a set of CHRs, g a 
function symbol. We say function g has type Va.C" t' w.r.t. P iff (1) We 
have that g{t,l) C,l = {h,l g ) for some constraint C, (2) <j), the m.g.u. of 
C,l = (h,l g ) exists, (3) let D C <j){C) such that D is maximal and D consists 
of unmarked user-defined constraints only, (4) let a = fv{D, <f>t) — fv(cj)li), (5) let 
C = <j){C) andt' = 4>{t). 

Example 9. According to Example[S]we find that g has type \/ti.{Erk a, Foo t\) => 
t\. Note that Erk a arises from f 's program text. 

We are able to state soundness of our approach. 

Theorem 1 (Soundness). Let P e , P p and Pi n u be three sets of CHRs, h a 
CHR in Pinit , r an environment of simply-typed bindings, Pmit o,n environment 
of primitive functions, e an expression, Ei n u a set of predicate symbols, C a 
constraint and t a type such that (Pinit, Ei n it) models Pi n %t and r,Ei n n,e \~c 
(C I t) and h, r, Ei n it, e \~r Pe and type checking of all annotations in e is 
successful. Let C ^p pU p init uP a ^' f or some constraint C 1 . Let (f> be the m.g.u. of 
C where we treat all variables in r as Skolem constants. Then, (j)(C r ),<f>(r) U 
Pinit \- e : (f>(t). 

The challenge is to identify some sufficient criteria under which our type 
inference method is complete. Because we only check for subsumption we need 
to guarantee that each subsumption condition will be either true or false. E.g. in 
Example[2]the subsumption condition boils down to the constraint Vt x .Foo t y t x . 
Note that we can satisfy this constraint by setting t y to either Int or Bool. Hence, 
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our task is to prevent such situations from happening. In fact, such situations can 
never happen for single-parameter type classes. But what about multi-parameter 
type classes? The important point is to ensure that fixing one parameter will 
immediately fix all the others. That is, in case of \lt x .Foo t y t x we know that 
t x is uniquely determined by t y . We can enforce such conditions in terms of 
functional dependencies | JonOOj . 

Definition 6. We say a type class TC is fully functional iff we find a class 
declaration class TC ai ... a„ I f di , . . . , fd„ where fdi = a$ -> ai ... 

a i — 1 a i+l • • • a n- 

We argue that for fully functional dependencies solutions (if they exist) must 
be unique. In fact, this is not sufficient because there are still cases where we 
need guess. 

Example 10. Consider the following simplified representation of the Show class. 

class Show a where 

show : : a->String 

read : : String->a 
f : : Show a => String->String 
f x = show (read x) 

The subsumption check boils down to the formula \fa.Show a D 3a' .Show a' 
which is obviously a true statement (take a' = a). However, in our translation 
to CHRs we effectively check for Show a <-> Show a' which obviously does not 
hold. 

There are further sources where we need to take a guess. 

Example 11. Consider 

class Foo 
instance Show Int 
instance Foo a => Show a 

where P p = {(SI) Show Int ^==> True I (S2) Show a ^=4> Foo a}. We have that 
P p \= Show Int. However, Show Int >-^s2 Foo Int where |= Foo Int <A True 
which suggests that P p |= Show Int might not hold. Clearly, by guessing the 
right path in the derivation we find that Show Int >— >si True. 

To ensure that our subsumption check (Definition is complete we need to 
rule out ambiguous types and require that the type class theory is complete. A 
type is ambiguous iff we can not determine the variables appearing in constraints 
by looking at the types alone. The annotation f : : Show a=>String->String in 
Example 1 101 is ambiguous. A type class theory P p is complete iff P p is confluent, 
terminating and range-restricted (i.e. grounding the lhs of CHRs grounds the 
rhs) and all simplification rules are single-headed. The type class theory P p in 
Example 1111 is non-confluent. In SS02 we have identified these conditions as 
sufficient to ensure completeness of the Canonical Normal Form procedure to 
test for equivalence among constraints. 

Theorem 2. Let P p a complete and fully functional type class theory. Then 
our CHR-based inference scheme infers principal types if the types arising are 
unambiguous. 
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4 Related Work and Conclusion 



Simonet and Pottier [STf)4| introduce HMG(X) a refined version of HM(X) |USW99ISul()0| 
which includes among others type annotations. Their type inference approach is 
based on the "allow for more solutions" philosophy. Hence, they achieve com- 
plete type inference immediately. However, they only consider tractable type 
inference for the specific case of equations as the only primitive constraints. 

An approach in the same spirit is considered by Hinze and Peyton- Jones HJOO . 
They sketch an extension of Haskell to allow for "higher-order" instances which 
logically correspond to nested equivalence relations. As pointed out by Faxen |Fax03| . 
in such an extended Haskell version it would be possible to type the program in 
Example[21 We believe this is an interesting avenue to pursue. We are not aware 
of any formal results nor a concrete implementation of their proposal. 

Pierce and Turner |PT00j develop a local type inference scheme where user- 
provided type information is propagated inwards to nodes which are below 
the annotation in the abstract syntax tree. Their motivation is to remove re- 
dundant annotations. Note that Peyton- Jones and Shields |PJS04j describe a 
particular instance of local type inference based on the work by Odersky and 
Laufer's OL96 . In our approach we are able to freely distribute type information 
across the entire abstract syntax tree. Currently, we only distribute information 
about the types of lambda-bound variables and type class constraints. We be- 
lieve that our approach can be extended to a system with rank-k types. We plan 
to pursue this topic in future work. 

In this paper, we have presented a novel inference scheme where the entire 
type inference problem is mapped to a set of CHRs. Due to the constraint-based 
nature of our approach, we are able to make available the results of inference for 
outer expressions while inferring the type of inner expressions. We have fully im- 
plemented the improved CHR-based inference system as part of the Chameleon 
system |SW] Our system improves over previous implementations such as Hugs 
and GHC. For some cases, e.g. unambiguous Haskell 98 programs, we can even 
state completeness. We note that our improved inference scheme can host the 
type debugging techniques described in SSW03 SSW(2]- 

In future work, we plan to follow the path of Odersky and Liiufer OL96 
and compute (non-principal in general) solutions to subsumption problems. We 
strongly believe that our improved CHR-based inference will be of high value 
for such an attempt. Another alternative inference approach not mentioned so 
far is to only generate all necessary subsumption problems <7j < a a and wait 
for the "proper" moment to solve or check them. Of course, we still need to 
process them in a certain order and might fail for the same reason we failed 
in Example 2] Clearly, our constraint-based approach allows us to "exchange" 
intermediate results among two subsumption problems which may be crucial for 
successful inference. 
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A Variations 

Our exisiting translation to CHRs is slightly lazier than most inference algo- 
rithms in the sense that we do not infer the types of let-bound variables which 
are never called. 

Example 12. Consider: 

f x = let g = x x 
in x 

We generate CHR rules that look like the following: 

f(t) ^t = t x ^t x 
g(t) <^=^ t x =t x — > t 

Since the / rule never calls g, the unsatisfiable constraint is not introduced, 
and this program is considered well- typed. 

This "laziness" can be problematic whenever we need to compare the inferred 
type of some function with its declared type. Consider an annotated function g, 
nested within the definition of function /, from which we generate an inference 
rule, g(t,l) g a (t,l),Ci, and an annotation rule, g a (t,l) •<=>• /(£', 1')q, C a . 
It's possible that the types of some global variables are affected in g, but not in 
g a . In order for g(t, I) and g a (t, I) to be equivalent, we depend on g's context, as 
called in the g a rule, to in turn call g and introduce those missing constraints. 

Example 13. Consider the following program. 

f y = let g : : Bool 

g = y 

in 'a' 

We generate the following (simplified) CHR rules: 

f(t,l)^t = Char, l = (Q,(ty}) 
g(t,l)*=*t = t v , i = «*»>, <ty», g*(t,l) 

gait, l)<=>t= Bool, I = ((ty), (ty)), f(t', I) 

Even though g's type annotation is acceptable, out subsumption check would 
fail, because g(t,l) and g a (t,l) are not equivalent wrt the I component. Clearly, 
the g rule implies t y — Bool, but the g a rule does not. 

We can remedy this situation by ensuring that all nested functions are called 
by their parent function. In this way, when we consider a function annotation, 
the definition of the function becomes part of its context. 

Example 14. We modify the program of Example ^3 forcing f to call g, but 
disregard its value. 

f y = let g : : Bool 

g = y 

in const 'a' g 
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The CHR rule associated with f would now look something like: 



f(t,l) 




a, 



This solves our immediate problem, in that the constraints arising from g(t, I) 
and g a {t, I) are now cquialcnt wrt t and I. 

Unfortunately this does not work in the case where the function we call is 
recursive. Consider: 

f y = let g : : Bool 

g = const y g 
in 'a' 

Here, if f were to call g, the constraint generated to represent g's type would 
be g a (t',l'). We then face the same problem, that from within g a we have no 
association between t y and Bool. 

Clearly, a syntactic transformation of the source program to introduce calls 
to otherwise uncalled functions is not sufficient. We must modify the CHR gen- 
eration process to directly insert calls to the inference constraints of functions 
which are not already called. 

Example 15. We return to the rules generated in Example 1131 The following 
CHR rule is a modified version of the / rule above which now contains a call to 
<7, further constraining the lambda-bound type variables. 



Using this modified rule, we see now that g(t, I) and g a (t, I), are equivalent, 
since t y = Bool in both. The mark on the g constraint is not significant 
here, though it does accomodates the simpler form of cycle breaking (by sim- 
ply removing the repeated constraint) than the equivalent unmarked constraint 
would. 

B Monomorphic Recursive Functions 

In case of monomorphic recursive functions (i.e. recursive functions with no type 
annotation) we need to update our strategy for breaking cycles among CHRs 
(Definition [2}. We denote by NRF the set of all non-recursive functions, by 
MRF the set of all recursive functions which carry no type annotations and by 
ARF the set of all annotated recursive functions. 



Definition 7 (CHR Cycle Removal). Let f(t,l) e G C and f(t',l% £ C 
where f G NRF U ARF and a derivation ...>—» C >—►... >— ► C". Then, ...>—> C >— > 

... C ■<<!<(■' f^'.l'l . 

Let f(t,l) G C and f(t',l')Q G C where f G MRF and a derivation ... >— ► 

... wC". Then, ... ^ C >-> ... >-> C ^ccrC - f(f ',l') e ,t' = t. 
Let f(t,l) G C and f{t',l') G C where f G MRF and f(t',l') is known 



to arise from the exact same program source location as f(t,l), and given a 
derivation ... >— » C >— > ... >— » C' . Then, ... >— > C >— > ... >— > C >— *Mono C — 



f(t,l) 



t = Char, i= «>,<*»», 9{t',l)e 
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Note that according to the definition of a >-^Mono step, we should only ever 
break cycles amongst constraints representing unannotated, recursive function 
types when they arise from the same program location. Unifying the types of 
different calls to the same function is overly restrictive, as the following example 
illustrates. 

Example 16. Consider the following program. 

e = let f = f 

in (f : :Int, f : :Bool) 



The two fs in the body of e are calls to the same recursive, unannotated 
function, i.e. f £ MRF. It would be unnecessarily restrictive, however, to ag- 
gressively apply >-*Mono here and unify the types of the two f s, resulting in a 
type error. Indeed, these two f s are not even part of the same cycle. 

We note that breaking cycles among constraints arising from the exact same 
program source location is sufficient. 

Example 17. Consider 

f = ... fx ... f 2 

where we added numbers 1 and 2 to different uses sites of f . Here is a sketch of 
type inference where we annotate >— > to refer to the number of CHR steps applied 
so far. / >— /i,/2 >— ►/ /i,2, f%- In the last step we reduce a call to / at 
location 1. Note that we make use of a refined marking scheme. We keep track 
of the original source location and add the location of the constraint introduced 
to the store to the existing locations. We refer to SSW03 for the details of such 
a "location-history" aware refinement of the CHR semantics. Hence, applying 
rule (Mono) twice will remove fi t i and /1.2 (and equate the types of and 
A, 2 with /). Similarly, we remove the cycles created by / 2 . 

We note that for >—>ccr there is no need to equate the I component in case 
of / g MRF. The I component is always set at the use site of functions (see 
constraint generation rules (Var-f)). Equating the I component would yield a 
strictly weaker system. 

Example 18. Consider f x = ( fi . . . , let g y = ... f2 ...in g) where 
we added numbers 1 and 2 to different (monomorphic) uses sites of f . Here 
is a sketch of type inference / >— »™ ...fx, ...,<? ^ n + m ...f ll ...,fz where natural 
numbers n and m refer to the number of CHR steps applied so far. Assume we 
fully equate /1 and fi. Note that their local k components differ (because this 
component is always exact!) Hence, type inference fails. 

Note that (as before in case of ARF and NRF) we only break cycles among 
constraints which carry the same marker. This yields a more precise method. 

Example 19. Assume we have situation where 

...~/(/nt),...~...~/(i) e ,... 
Removing f(t) Q and adding t = Int might be too restrictive. 
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Note that by construction >—>Mono never applies to ARF and NRF. Any 
potential cycle will be eventually broken. We can re-establish Lemmas [21 and 
and state a slightly stronger Lemma[I] which guarantee soundness of our CHR- 
bascd inference approach. 

Lemma 3 (CCR-Mono Soundness). Let P be a set of CHRs and C and C 
two constraints such that C ^->p C" . Then P |= 3f v ^C D C. 

Note that P \= C D 3f v (c)C does not hold anymore. We may reject typable 
programs because we stricly enforce the (Mono) rule. 

Example 20. Consider 

h x = (hi 'a') && (h 2 True) 

Here is a sketch of type inference. 

h(t) 

>— > t = tx —> Bool,h\(Char — > Bool), h2(Bool — » Bool) 

>— > t = tx — > Bool, Char — > Bool = tx' — > Bool, h\ t i(Char — > Bool), 

h\.i(Bool — > Bool), h2(Bool — > Bool) 
^Mono t = tx — > Bool, Char — > BooZ = tx' — » Bool, Char — > Boo/ = Char — > Bool, 

h\ 2(Bool — ► Bool), h2(Bool — » Bool) 
^Mono t = tx — > Bool, Char — > BooZ = iir' — » Bool, Char — > _Boo^ = Char — ► Bool, 

Char — > _Boo^ = Boo/ — * Bool, h2(Bool — ► Bool) 
<-» False 

It is interesting to note is that our type inference scheme for recursive func- 
tion is more relaxed compared to the one found in some other established type 
checkers. 

Example 21. Consider the following program. 

e : : Bool 
e = g 

f : : Bool -> a 

f = g 
g = f e 

In the case of GHC, the following error reported is: 

mono-rec . hs : 5 : 

Couldn't match 'Bool -> a' against 'Bool' 
Expected type: Bool -> a 
Inferred type: Bool 
In the definition of 'f: f = g 

The problem reported here stems from the fact that within the mutually 
recursive binding group consisting of e , f and g, f is assigned two ununifiable 
types, Bool and Bool — > a: the first because it must have the same type as g, 
which according to e must be Bool; and the second because of its type declara- 
tion. 
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Our translation scheme is more liberal than this, in that g's type within e 
and f may be different. Essentially, we only require that the type of a variable 
be identical at all locations within the mutually recursive subgroup if a type 
declaration has been provided for that variable. 

(Simplified) Translation of the above program to CHRs yields. 

e a (t) t = Bool 
e(t) 

f a (t) t = Bool — > a 

/(*) <=>s(t) 

g(t) e a (t e ), f a (tf), tf = t e —> Bool 

It is clear from the above that there are no cycles present amongst these rules. 
We can use them to successfully infer a type for any of the variables in the 
program. 

In fact, our handling of binding groups is similar to |Jon99j where type in- 
ference of binding groups proceeds as follows: 

1. Extend the type environment with the type signatures. In this case f : : f orall 
a. Bool -> a and e: :Bool. 

2. Do type inference on the bindings without type signatures, in this case g = f 
e. Do generalisation too, and extend the environment, giving g : : f orall 
a. a. 

3. Now, and only now, do type inference on the bindings with signatures. 
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